[Outreachy PATCH] prune-packed: remove use_the_repository_variable - #2266

On Sun, Oct 18, 2026 at 04:31:12PM +0000, Shashank S via GitGitGadget wrote:
> From: Shashank <shashu8660@gmail.com>
> 
> Right now, the prune_packed_objects() function uses the global

Nit: we typically refrain from saying "now", as it's implicitly clear
that you're describing the status quo in your commit message unless you
explicitly refer to an older commit.

> the_repository variable. To help with the libification effort,
> change this function so it takes a 'struct repository' pointer
> as an argument instead.
> 
> The function for_each_loose_file_in_source() uses a callback
> that only takes a single 'void *data' pointer. This means we
> cannot pass both the repository pointer and the 'opts' integer
> at the same time. To fix this, create a new 'struct prune_data'
> to hold both of them together, and update the prune_subdir() and
> prune_object() callbacks to read from this new struct.
> 
> Update the builtins that call this function (builtin/prune-packed.c,
> builtin/prune.c, and builtin/repack.c) to pass their local `repo`
> variables. Because we are now actually using the 'repo'  parameter
> in these files, we can safely remove the UNUSED macro from them.

The question isn't really whether we can safely remove the UNUSED macro.
The question is rather whether we can assume that `repo` always points
to a proper repository. And for that you need to research whether these
commands can be invoked outside of a repository, because if so the repo
may be `NULL`.

> finally, drop the USE_THE_REPOSITORY_VARIABLE macro from

s/finally/Finally

> prune-packed.c.
> 
> Signed-off-by: Shashank <shashu8660@gmail.com>

We typically ask contributors to spell out their full name, see
Documentation/SubmittingPatches [[real-name]].

The changes all look sensible to me, thanks!

Patrick

On Mon, 19 Oct 2026 at 12:39, Patrick Steinhardt <ps@pks.im> wrote:
>
> On Sun, Oct 18, 2026 at 04:31:12PM +0000, Shashank S via GitGitGadget wrote:
> > Right now, the prune_packed_objects() function uses the global
>
> Nit: we typically refrain from saying "now", as it's implicitly clear
> that you're describing the status quo in your commit message unless you
> explicitly refer to an older commit.
thank you for the  review and point the mistakes i have done i will
correct all the mistake and i will submit the changed commit in the V2
patch.

> > in these files, we can safely remove the UNUSED macro from them.
>
> The question isn't really whether we can safely remove the UNUSED macro.
> The question is rather whether we can assume that `repo` always points
> to a proper repository. And for that you need to research whether these
> commands can be invoked outside of a repository, because if so the repo
> may be `NULL`.
>

I have checked git.c file in that file I went through this commands .
prune , prune-packed and repack which are .
{ "prune", cmd_prune, RUN_SETUP },
{ "prune-packed", cmd_prune_packed, RUN_SETUP },
{ "repack", cmd_repack, RUN_SETUP },
All this commands are all registered with a special flags '
RUN_SETUP'. This flags search for .git folder . If it finds a .git
folder Git successfully initializes the repo struct and passes that to
valid pointer to your builtin . If it does not find a .git folder (if
they ran it outside the repository) Git immediately stops and shows
the error . It never run the code .

> > finally, drop the USE_THE_REPOSITORY_VARIABLE macro from
>
> s/finally/Finally
i will change this too.
>
> > prune-packed.c.
> >
> > Signed-off-by: Shashank <shashu8660@gmail.com>
>
> We typically ask contributors to spell out their full name, see
> Documentation/SubmittingPatches [[real-name]].
>
> The changes all look sensible to me, thanks!
>
> Patrick
Thank you

Shashank S <shashu8660@gmail.com> writes:

>> The question isn't really whether we can safely remove the UNUSED macro.
>> The question is rather whether we can assume that `repo` always points
>> to a proper repository. And for that you need to research whether these
>> commands can be invoked outside of a repository, because if so the repo
>> may be `NULL`.
>
> I have checked git.c file in that file I went through this commands .
> prune , prune-packed and repack which are .
> { "prune", cmd_prune, RUN_SETUP },
> { "prune-packed", cmd_prune_packed, RUN_SETUP },
> { "repack", cmd_repack, RUN_SETUP },
> All this commands are all registered with a special flags '
> RUN_SETUP'. This flags search for .git folder . If it finds a .git
> folder Git successfully initializes the repo struct and passes that to
> valid pointer to your builtin . If it does not find a .git folder (if
> they ran it outside the repository) Git immediately stops and shows
> the error . It never run the code .

The analysis is not entirely correct.  Assuming that your system
administrator is not insane enough and did not make the entire
filesystem as a working tree of a repository,

    $ cd / && git repack -h

does call cmd_repack() with "repo" set to NULL.

The call to parse_options() will give the short help and exit.
Becaues the references to "repo" you added all happen after the code
already called parse_options(), your update will not make the code
dereference NULL.  Some subcommands with tricky call sequence into
parse_options() _may_ have to be a bit more careful than just
checking "are we using RUN_SETUP?".  Of course RUN_SETUP_GENTLY is
an explicit sign that you have to be prepared to see NULL in "repo".

Thanks.